Agent skills

Turning on curated skills, how an agent reads one over MCP, and what carrying somebody else's work means.

A skill is procedural knowledge an agent loads when a task calls for it — how to drive test-first development, how to read a stack trace, how to instrument a service before shipping it. It is a directory with a SKILL.md at its root, in the format Anthropic released as an open standard and roughly forty clients now read.

Omniio carries 74 of them. Four are its own, about operating this gateway. The rest are other people's, listed in the catalogue with the author credited and the licence they ship under.

What you get, and what it costs#

No new tools: tools/list still returns search_tools, describe_tool and run_tool. Skills ride on protocol methods your client calls, which the model never sees.
Only what you turned on: The catalogue is browsed here; your endpoint publishes the ones you enabled. A listing of seventy-four skills is the context cost this product exists to remove.
Nothing to install: The instructions arrive over the connection your client already has. Only a skill that bundles executables needs anything on your disk.

Turning one on#

Open Skills, find one, and use the switch. It takes effect on your client's next connection — there is no credential to connect and nothing upstream to reach, because the content is already in the deployment.

How an agent reads one#

Skills over MCP follow SEP-2640, the Skills Over MCP working group's extension. Omniio declares it at initialization as io.modelcontextprotocol/skills with directoryRead: true, which commits the endpoint to three methods.

skills/list: Every skill this account is served, each entry carrying the SKILL.md's frontmatter verbatim and a complete list of the skill's files with a SHA-256 for each.
skills/get: One entry, by the URI of its SKILL.md. This is how a client refreshes one skill’s digests without re-enumerating, and how a skill it was handed rather than listed still gets verified.
resources/directory/read: The direct children of a directory inside a skill, so an agent told to “use the template in templates/” can find out what is in there. Subdirectories come back marked inode/directory.

Files themselves are read with ordinary resources/read. Every file of a skill is addressable:

skill://obra/test-driven-development/SKILL.md
skill://anthropics/mcp-builder/reference/evaluation.md
skill://anthropics/mcp-builder/reference/python_mcp_server.md

The last path segment before the file is the skill's name; the segment in front of it is the author. That prefix is what makes the catalogue's collisions harmless — obra and addyosmani both publish a test-driven-development, and the URIs say which is which.

Skills that ship scripts#

Some skills bundle executables — a script that packs an artifact, a helper that renders a frame. Those run on your machine, not Omniio's, so the files have to land on your disk. Every such skill's page carries the one line that does it:

terminal

mkdir -p ~/.claude/skills && curl -fsSL https://omniio.dev/skills/obra/brainstorming/archive | tar -xzf - -C ~/.claude/skills

That directory is where every client following the specification looks for filesystem skills, and the archive's root is the skill's own name, which is what the format requires the directory to be called. The instructions stay readable over MCP either way; the install is only for the parts that execute.

Where they come from#

Every third-party skill is copied into this repository at a commit recorded by hash, with its licence file beside it, and served from there. Nothing is fetched from GitHub when your agent reads one.

Licence: Resolved per skill from the file that ships with it, not from the repository's metadata. Anything that is not MIT or Apache-2.0 is excluded, and the licence travels as one of the skill's own files so it reaches your agent with everything else.
Commit: The full object name the content was copied at, on every skill's page and in the resource's metadata. Refreshing the catalogue is a commit here, reviewable as a diff.
Author: Credited on the page, in the catalogue listing, and in the metadata attached to the resource your agent reads.

The four about this gateway#

Written here rather than borrowed, and every claim in them checkable against the code that produces the behaviour:

finding-and-calling-tools: The search → describe → run loop, and the argument names that fail on a first attempt.
handling-held-and-refused-calls: What to do with an approval hold, a policy refusal, or a quota message, instead of retrying blindly.
connecting-a-server: What the library is, which servers need a credential, and how to tell a user what to do.
limits-and-retries: Burst and monthly limits, what the headers mean, and when a retry is the wrong answer.

Where to go next#

The catalogue — every skill, grouped by what it is for
Your skills — turn them on
The three tools — what skills sit beside