你的智能体遇到一个它无法完成的任务——读取A股市场数据、让第二个模型审查diff、转录访谈、去除水印、克隆某个网站的设计系统。在某个地方，有一个技能文件可以解决这个问题。找到它才是麻烦的部分。
这个服务器在智能体内提供了一个小而精的精选目录。它进行搜索、读取交付信息，并准确告诉你该运行什么。免费项目附带直接下载链接；付费项目则标明价格，不做推销。
该目录是 agentskill.nz。它刻意保持小规模。公开的技能目录包含数十万条未经审核的条目——实测平均质量约为12分中的6分，大约三分之一存在提示注入风险。这里的每个条目都附带其功能、运行所需条件、测试环境以及适用边界。
Related MCP server: SkillFlow MCP Server
无需安装步骤。将你的 MCP 客户端指向它：
{
"mcpServers": {
"agentskill": {
"command": "npx",
"args": ["-y", "github:simonlin1212/agentskill-mcp"]
}
}
}Claude Code：
claude mcp add agentskill -- npx -y github:simonlin1212/agentskill-mcp首次安装时会进行构建，因此第一次运行会比后续运行多花几秒钟。 （npm 版本尚未发布；目前支持从仓库安装。）
需要 Node 18+。无需配置，无需 API 密钥，无需账户。服务器不保存任何状态，也不会在你的机器上写入任何内容。
工具 | 回答的问题 |
| “有没有适合 X 的东西？” 按自由文本、模块或价格层级筛选。 |
| “我到底能得到什么，以及如何获取？” 版本、包大小、最后更新、源仓库和获取路径。 |
| “这里面有什么？” 四个模块、它们的数量，以及两种交付形式的含义。 |
搜索在同一个索引中同时支持中文和英文，因此 去水印 和 remove watermark 都会指向同一条目。无论你输入哪种语言，结果都会同时显示两种名称。
四个模块——金融、商业、创作者、通用——包含两种形式：
安装技能 — 智能体加载的技能文件。将其复制到智能体的技能目录中。
部署应用 — 带有独立 UI 的可运行应用。部署后，与智能体一起使用。
大约一半的条目是免费的。其中一些是开源仓库的打包形式，合计拥有 16,000+ GitHub 星标；如果某个能力基于上游项目，产品页面上会注明上游项目及其许可证。
这是一个目录工具，不是广告位。它遵守三条规则：
免费就是免费。 目录发布下载链接的地方，工具会直接提供——无需账户，无需门槛。（免费条目偶尔可能还没有已发布的存档；它会明确说明。）
付费则标明价格并停止。 没有紧迫感，没有推荐用语。付费项目的下载链接在结账后通过订单页面和电子邮件发放。
具体来说：目录中未明确标记为 free 的任何内容都被视为付费（失败时关闭），其下载字段会被移除，名称、结果、安装、来源和仓库字段中的 URL 会被剥离，组装后的输出会经过路由白名单检查。唯一能保留的网址是 https://agentskill.nz（可选在 /zh 下）上的：站点根目录、/products/<handle>、/collections/<handle>、/pages/<handle> 以及 /cart 或 /cart/<variant>:<qty>——每个都作为完整路由匹配，因此像 /products/x/download 这样的更深路径不符合条件。任何其他内容——其他主机、纯 http、相似域名、/download?id=…——都会导致服务器拒绝返回该记录。
这不涵盖的情况：没有协议方案的裸主机名（evil.example/x）。要捕获这些，就需要将任何类似域名的文本视为地址，而 .md 是一个真实的顶级域名——交付清单中的 SKILL.md 会被当作域名而拒绝，从而破坏所有付费列表。这些响应是纯文本，因此裸主机名只有在后续处理中变成链接时才会成为链接。
值得指出的差距：目录缓存最长五分钟。在该窗口内变为付费的项目仍会从之前的快照中描述——包括它免费时拥有的直接下载 URL。
安装命令是信息，不是授权。 get_capability——唯一返回安装命令的工具——每次调用都会说明这一点。你的智能体在写入你的文件系统或花费你的钱之前，应与你确认。
目录 URL 在运行时从站点的 /llms.txt 发现，而不是硬编码，因此当站点轮换它时，服务器仍能正常工作。
npm install
npm run build
node test-smoke.mjs # drives the server over real MCP stdiotest-smoke.mjs 直接使用线上协议而不是导入模块，因此它能捕获单元测试可能遗漏的注册和传输故障。它还断言任何付费项目都不会返回文件 URL。
参见 CHANGELOG.md。
此服务器读取目录并返回其内容。它不评估某个能力是否适合你的用例，也不执行任何操作。技能文件是你的智能体会读取并执行的代码——使用前请审查它们，就像对待任何依赖一样。
如果这为你节省了时间 ☕
MIT
作者： Simon Lin · X @linsizhen · 邮箱：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.
v0.1.0get_capabilitylist_modulessearch_capabilitiesScored across 3 tools
Each 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.
Search and load AI agent skills. Free metadata; full content requires a Pro or Studio account.
Search and fetch curated AI agent skills, prompts and MCP servers.
Find AI agent skills: public previews and source links. Read-only discovery; no account required.
Find and try paid AI agent skills for security, on-chain data, code, markets, research and news.
