Moltline vs Registry Model for SKILL.md: What You Get

Professional header image for comparison analysis: Moltline vs the Registry Model: What You Get for SKILL.md

curl -sS https://moltlinestudio.com/api

Run that and a live x402 HTTP 402 challenge comes back. A machine-readable handshake, not a docs page. That is the difference this whole comparison turns on.

The question keeps arriving in AI chat windows: for SKILL.md work, do you point your repo at a studio catalog or at a registry model? The short answer depends on who owns your spec.

This post compares what each option concretely provides. You will learn:

How to wire a Moltline MCP endpoint into Claude Code
What the 138 open SKILL.md skills on GitHub (github.com/GarphenGate/moltline-oss) give you, and what the free linter and agent-readiness checker verify
Where a registry model fits better than a studio catalog, and the questions to ask before you commit

Expect a comparison table, exact commands, and a setup path for Claude Code or Cursor. Facts here come from the Skilldex paper and client-supplied Moltline figures. Where a claim needs a source, it gets a link. Start with the install, then judge the model.

How to wire a Moltline MCP endpoint into Claude Code

Check the current syntax in the Claude Code CLI reference before running; flags change between releases.

claude mcp add --transport http moltline https://mcp.moltlinestudio.com/<server>

Run /mcp inside Claude Code to confirm the connection. You already know what SKILL.md is and you already have a client installed. What you do not know yet is what each delivery model actually hands you.

Cursor and Codex read the same URL from a project-scoped .mcp.json. Verify the key name against the current Cursor docs at cursor.com/docs/mcp before applying:

{
 "mcpServers": {
 "moltline": {
 "type": "http",
 "url": "https://mcp.moltlinestudio.com/<server>"
 }
 }
}

<server> is a placeholder. The real slugs sit on the servers page. The endpoint is a direct Streamable HTTP URL, not a proxy. Per the MCP transport spec, each message is an HTTP POST to a single endpoint, so there is no intermediary to debug. The free tier needs no API key and no signup.

Is a studio catalog or a skill registry better for your repo

Your repo does not care which model looks larger. It cares who owns the code path when a tool call fails.

Registry-model answers depend on the specific vendor. Read the table below as a checklist for questions to ask, not as a ranking.

Row	Moltline Studio	Registry or marketplace model
Who writes the skills	One person at the studio writes each skill and server	verify with the vendor
Where the files live	138 open SKILL.md files in GarphenGate/moltline-oss; server list on the servers page	verify with the vendor
How you install	Paste a direct Streamable HTTP endpoint, or clone the repo	verify with the vendor
Cost model	22 hosted servers, 160 tools; 110 free with no account; 50 unlocked by a $19/month All-Access licence	verify with the vendor
Who runs the server	The builder runs mcp.moltlinestudio.com/	verify with the vendor
Who fixes breakage	The builder. One person, no round-the-clock desk	verify with the vendor
What you can verify before install	Every server page and the public repo, checkable in one click	verify with the vendor

A studio ships what it built and runs the endpoint itself, so one party owns the code and the uptime. A registry brokers files it did not write, often from many authors, and usually hosts an index you install from. Your risk shifts to provenance and dependencies you did not author.

What Moltline Studio actually gives you for SKILL.md work

Three things sit behind the SKILL.md work, all free, no account needed:

138 open SKILL.md skills in the GarphenGate/moltline-oss repo on GitHub
A free SKILL.md linter
A free 21-check agent-readiness checker at moltlinestudio.com/agent-check.html

Count the skills yourself:

git clone https://github.com/GarphenGate/moltline-oss.git
ls moltline-oss/skills | wc -l

The count moves as skills land, so run it against a commit hash if you need a fixed number.

A SKILL.md file is a folder whose SKILL.md opens with a frontmatter block naming the skill and describing when to use it. Below that sit instructions, and optionally scripts, that the agent loads on demand rather than at startup.

The repo is the source of truth for the 138 figure. Nothing in it is gated.

One caveat: this is a one-person studio. The same person builds the skills, runs the servers, and writes the docs. There is no support desk behind the endpoint.

How to install agent skills in Claude Code and Cursor

Clone the repo first, then wire the endpoint. For Claude Code, use the CLI route covered in the wiring section above. Check the current syntax in the Claude Code CLI reference before running; flags change between releases.

For Cursor, paste the endpoint into .cursor/mcp.json at the project root as shown in the wiring section. Verify the key name against the current Cursor docs at cursor.com/docs/mcp.

Dropping in a skill folder

Copy the cloned skill into the directory your client scans, then let the agent read it from that path. Confirm the skills directory path in the Claude Code skills docs before copying:

cp -r moltline-oss/skills/<skill> ~/.claude/skills/

Cursor scans .cursor/skills/ inside the project, so the same folder name works there. Check cursor.com/docs/skills for the current scan path.

Reload before you debug

MCP servers load when the client starts. Restart the CLI or reload the Cursor window after editing config. If tools do not appear, run /mcp and confirm the server shows as connected before you touch anything else.

Free vs paid MCP tools: where does the line sit

Once the config is in place, the next question is what you are actually paying for. The 22 hosted servers include 160 tools total. 110 are free forever with no account, no API key, and no signup. The other 50 need the $19/month All-Access licence. One licence covers the premium set; billing is not per tool. Payment is in cryptocurrency, through NOWPayments at checkout or as 19 USDC on Base when an agent buys the month over x402.

You can read the price from the client side instead of a marketing page:

curl -i https://moltlinestudio.com/api

The request returns HTTP 402 with the price attached. An agent can read the cost and settle on-chain without a human in the loop.

What stays free regardless of licence:

The 138 SKILL.md skills in GarphenGate/moltline-oss
The SKILL.md linter
The 21-check agent-readiness checker at moltlinestudio.com/agent-check.html

What a SKILL.md linter checks and what agent readiness means

Those free items do different jobs. The linter checks the file. The readiness checker checks the site.

A SKILL.md linter parses the YAML frontmatter first. It confirms required fields exist and are well formed. The spec requires name (1 to 64 characters, lowercase alphanumeric and hyphens) and a non-empty description up to 1024 characters (specification). It then reads the Markdown body for structure the loader can follow without choking on malformed headings or fences.

An agent-readiness checker grades whether a site exposes machine-readable signals an agent can act on without a human reading the page first. Typical signals:

an llms.txt file at the root
a published API catalog
structured data such as schema.org markup
endpoints that answer without a browser session

This matters before you publish a skill. Malformed frontmatter can fail at load time. If your client loads the skill without complaint but never fires it, check the file before debugging the agent. That is why treating SKILL.md as a readiness signal is practical, not theoretical.

Neither tool is a guarantee. A linter is not a security review. A readiness grade is not a compatibility promise for every client version. Test the clients you actually run.

When is a skill registry a better fit than a studio catalog

A clean linter run tells you the file parses. It does not tell you who maintains the skill next quarter. That gap is what separates a studio catalog from a registry.

A registry is the better fit when:

You need breadth past one studio's catalog.
You want skills written by authors you did not hire.
You would rather not own the client config at all.

The studio model has real limits: one person builds and runs everything here, catalog growth is slower than a pooled index, and there is no round-the-clock support desk behind the endpoint.

A registry makes a trade in return. You inherit its vetting and its outages for every skill you install. Version pinning depends on the registry's index, not on your repo, so an upstream change can land mid-sprint.

Scoring a named registry would require that vendor's own current documentation and a linkable result URL. This piece has neither, so it does not grade one. Read the comparison table above as model-level reasoning, not as a ranking. If the registry model still looks right for your repo, the next section lists what to verify before you wire anything in.

Questions to ask any skill registry before you commit

A registry earns its place when you need skills from outside authors. Five questions decide whether it stays a dependency or becomes a liability.

Who owns the spec? Does the vendor emit the published SKILL.md format unchanged, or a variant only its own client parses? Diff a sample file against the spec's required frontmatter fields before install.
Where do the files live? Export a skill and load it in a second spec-compliant client. If install writes into a hosted index you cannot fork, you do not own the file.
What is the cost unit? Per seat, per install, per request, or a free tier with a hard stop. Get the number and the cap in writing before you wire anything in.
Who runs the server? A third-party host you cannot debug, or an endpoint you can curl yourself. Run curl -i and check whether a failed tool call leaves a readable trace.
What happens when a skill breaks? Ask who owns the fix and how updates land. The spec has no required version field, so pinning depends on the registry's mechanism, not your repo. An upstream edit should not land mid-sprint.

A registry that answers all five in writing is a reasonable dependency. One that answers vaguely is a dependency you cannot debug.

Where to start with SKILL.md skills today

If those registry questions came back with answers you can live with, the registry model is viable. If they did not, here is the shortest path to running SKILL.md skills today.

Start with one command. Point it at any server slug from the servers page. Check the current syntax in the Claude Code CLI reference before running; flags change between releases:

claude mcp add --transport http moltline https://mcp.moltlinestudio.com/<server>

No API key. No signup. 110 of the 160 tools are free forever. If you would rather work on files first, count what is there as shown in the clone step above, then lint a SKILL.md you already wrote, or one from the folder.

Two places to go next, neither of them a signup flow:

github.com/GarphenGate/moltline-oss for the 138 open SKILL.md files.
The servers page for the endpoint slugs.

Decision rule: pick the studio catalogue when you want files you can read and endpoints you can test. Pick a registry when you need third-party breadth and will accept someone else's vetting.

Conclusion

The model comparison is above. The command and the repo are in the final section above -- no API key, no signup, run either one first.