This MCP server lets an agent search a vetted catalog of AI-agent capabilities (skills and small apps), fetch full details for one, and browse the catalog's modules.
Search capabilities (search_capabilities) – find skills/apps by free text (Chinese or English), or filter by module (finance, ecommerce, media, general) or price tier (free/paid). Results include name, module, form, price, version, size, and direct download URL for free items.
Get capability detail (get_capability) – retrieve complete info for a specific capability by ID: version, package size, last update, source repository, licence facts, and exactly how to obtain it.
List modules (list_modules) – get an overview of the catalog's four modules, their counts, and what the two delivery forms (Install Skill vs. Deploy App) mean.
Install or deploy – free items provide a direct download link; paid items show the price and an allowlisted purchase route. The server informs the agent of install commands but leaves final execution to the user.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agentskill-mcp Find a skill to remove watermarks from images"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
The author is open to AI roles in Shenzhen, particularly in AI-powered investment research products, Forward Deployed Engineering (FDE), and AI consulting or solutions at Tencent, other leading technology companies, and financial institutions.
He combines experience in financial institutions with hands-on AI product development, building open-source market data tools and multi-agent systems with 17K+ GitHub stars.
Contact: simonlin0423@gmail.com
Related MCP server: SkillFlow MCP Server
Your agent hits a task it can't do — read A-share market data, get a second model to audit a diff, transcribe an interview, remove a watermark, clone a site's design system. Somewhere out there is a skill file that would solve it. Finding one is the annoying part.
This server puts a small, vetted catalog inside the agent. It searches, reads the delivery facts, and tells you exactly what to run. Free items come with a direct download URL; paid ones come with a price and no sales pitch.
The catalog is agentskill.nz. It's deliberately small. Public skill directories carry hundreds of thousands of entries with no vetting — measured average quality around 6 out of 12, roughly a third carrying prompt-injection risk. Every entry here ships with what it does, what it needs to run, what it was tested against, and where it stops.
No install step. Point your MCP client at it:
{
"mcpServers": {
"agentskill": {
"command": "npx",
"args": ["-y", "github:simonlin1212/agentskill-mcp"]
}
}
}Claude Code:
claude mcp add agentskill -- npx -y github:simonlin1212/agentskill-mcpIt builds on first install, so the first run takes a few seconds longer than later ones. (An npm release is not out yet; installing from the repository is the supported route today.)
Requires Node 18+. Nothing to configure, no API key, no account. The server holds no state and writes nothing to your machine.
Tool | What it answers |
| "Is there something for X?" Filter by free text, module, or price tier. |
| "What exactly am I getting, and how do I get it?" Version, package size, last update, source repository, and the obtain path. |
| "What's in here?" The four modules, their counts, and what the two delivery forms mean. |
Search reads Chinese and English in one index, so 去水印 and remove watermark both land on the same
entry. Whichever you type, results carry both names.
Four modules — Finance, Commerce, Creator, General — holding two forms:
Install Skill — a skill file the agent loads. Copy it into the agent's skills directory.
Deploy App — a runnable app with its own UI. Deploy it, then use it alongside the agent.
Roughly half the entries are free. Several are the packaged form of open-source repositories with a combined 16,000+ GitHub stars; where a capability builds on an upstream project, the upstream and its licence are named on the product page.
This is a catalog tool, not an ad slot. Three rules it keeps:
Free means free. Where the catalog publishes a download URL, the tool hands it straight over — no account, no gate. (A free entry can occasionally have no published archive yet; it says so.)
Paid states the price and stops. No urgency, no recommendation language. The download link for a paid item is issued after checkout, on the order page and by email.
Concretely: anything the catalog does not explicitly mark free is treated as paid (fail closed), its
download field is dropped, URLs are stripped out of its name, outcome, install, source and
repository fields, and the assembled output is
checked against a route allowlist. The only web addresses that survive are, on https://agentskill.nz
(optionally under /zh): the site root, /products/<handle>, /collections/<handle>,
/pages/<handle>, and /cart or /cart/<variant>:<qty> — each matched as a whole route, so a deeper
path like /products/x/download does not qualify. Anything else — another host, plain http, a lookalike
domain, /download?id=… — makes the server refuse to return that record.
What this does not cover: a bare hostname with no scheme (evil.example/x). Catching those means
treating any domain-shaped text as an address, and .md is a real TLD — SKILL.md in a delivery
manifest would be rejected as a domain, breaking every paid listing. These responses are plain text,
so a bare hostname only becomes a link if something downstream linkifies it.
The gap worth naming: the catalog is cached for up to five minutes. An item that turned paid inside that window is still described from the previous snapshot — including the direct download URL it had while it was free.
An install command is information, not authorization. get_capability — the only tool that returns
an install command — says so on every call. Your agent should confirm with you before writing to your
filesystem or spending your money.
The catalog URL is discovered from the site's /llms.txt at runtime rather than hardcoded, so the
server keeps working when the site rotates it.
npm install
npm run build
node test-smoke.mjs # drives the server over real MCP stdiotest-smoke.mjs speaks the wire protocol rather than importing the module, so it catches registration
and transport breakage that a unit test would miss. It also asserts that no paid item ever returns a
file URL.
See CHANGELOG.md.
This server reads a catalog and returns what it says. It does not evaluate whether a capability suits your use case, and it does not execute anything. Skill files are code your agent will read and act on — review them before use, the same as any dependency.
If this saved you some time ☕
MIT
Author: Simon Lin · X @linsizhen · Email: simonlin0423@gmail.com
Full detail for one capability by id: version, package size, last update, source repository, licence-relevant facts, and exactly how to obtain it. Call this before installing anything.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Capability id, e.g. 'a-stock-data'. Get it from search_capabilities. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It discloses the output contents (version, repository, license facts, etc.) and implies a read operation via the tool name 'get.' Does not explicitly declare read-only or mention side effects, but is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence: it lists the output contents and gives a clear usage directive. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no output schema, no annotations), the description covers purpose, usage, and output details. It does not explain potential errors or explicitly confirm read-only nature, but overall is sufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single param with a description already stating 'Get it from search_capabilities.' The tool description does not add new parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides 'full detail for one capability by id' and lists specific contents (version, package size, etc.), distinguishing it from sibling tools like search_capabilities which likely return a list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Call this before installing anything,' providing a clear when-to-use instruction. The schema also notes the id should come from search_capabilities, implying a prerequisite. No explicit alternatives or when-not cases, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Overview of the catalog: the four modules, how many capabilities each holds, and what the two delivery forms mean.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns an overview of modules, capabilities, and delivery forms, but does not disclose whether the data is static, cached, or reflects real-time state. With no annotations, the description should clarify if this is a read-only, safe operation. A score of 3 reflects the description gives some useful behavioral context but lacks clarity on side effects or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 18 words, very concise. It is front-loaded with the purpose ('Overview of the catalog') and then lists what it covers. It could be slightly more structured (e.g., bullet points implied), but for zero-param tool it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description must explain what the tool returns. It mentions 'the four modules, how many capabilities each holds, and what the two delivery forms mean,' which gives a clear idea of the output structure. However, without any annotations or output schema, the description should also clarify whether the output is a list, a summary, or a single object. The description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters and schema description coverage is 100%. Since there are no parameters to document, the description is not required to add anything. A baseline of 4 is appropriate because there is nothing to clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb (list/overview) and resource (catalog of modules, capabilities, delivery forms). It distinguishes from siblings: siblings 'get_capability' and 'search_capabilities' imply focused queries, while this tool provides a high-level catalog summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is an overview tool, but does not explicitly state when to use it vs siblings. For example, it doesn't say 'Use this for broad orientation; use get_capability for details on one module, or search_capabilities for filtered queries.' Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the AgentSkill catalog of installable AI-agent capabilities (skill files and small apps). Use when the user wants a capability the agent does not have — reading A-share/US market data, auditing code with a second model, transcribing audio, upscaling or de-watermarking images, cloning a site's design, deploying an overseas store, and so on. Returns name, module, form, price, version, size, and a direct download URL for free items.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Restrict to free or paid. | |
| limit | No | Max results, default 10. | |
| query | No | Free text. Matches name, description, repository, module and form, in Chinese and English. | |
| module | No | Restrict to one module. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It explains that the tool returns specific fields (name, module, etc.) and mentions a direct download URL for free items, implying paid items may behave differently. It doesn't cover query behavior or side effects, but for a non-destructive search tool, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at three sentences, each earning its place: purpose, usage guidance with examples, return fields. Front-loaded with the core action. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters and no output schema, the description is fairly complete. It covers purpose, when to use, what is returned. Could mention how parameters affect results but the schema handles that. Sibling tools fill the remaining gaps. Not missing anything critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with each parameter already well-described (type, enum, constraints). The description adds overall context about free text matching and return fields but does not provide additional semantics beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'AgentSkill catalog of installable AI-agent capabilities'. It specifies the tool's purpose: to find capabilities the agent doesn't have. This distinguishes it from siblings 'get_capability' (likely detail) and 'list_modules' (module listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use when the user wants a capability the agent does not have'. It provides concrete examples (e.g., market data, image upscaling). It doesn't explicitly state when not to use or name the sibling tools as alternatives, but the use case is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_capabilitylist_modulessearch_capabilitiesEach tool has a clearly distinct purpose: search_capabilities for searching, get_capability for full details by ID, and list_modules for a module overview. There is no functional overlap or ambiguity.
All tool names follow a consistent verb_noun pattern with snake_case (get_capability, search_capabilities, list_modules), making the set predictable and easy to understand.
With exactly three tools, the set is well-scoped for a read-only catalog exploration interface. Each tool earns its place and together they cover browsing, searching, and detail retrieval without being too few or excessive.
The tool surface fully covers the expected workflows for a capability catalog: listing modules for orientation, searching for capabilities, and retrieving full details including download information. There are no obvious gaps for the stated consumer-facing purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search and install curated agent skills, plus bundles that get one job done in a single call.
Find, inspect and install reviewed reusable AI-agent capabilities from superskill.sh.
Search & install 6,500+ AI agent skills from skills-hub.ai inside any MCP tool.
Search your team's shared AI-skill library, get install commands, and save skills from your agent.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/simonlin1212/agentskill-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
