エージェントが処理できないタスクに直面したとします。A株のマーケットデータを読む、別のモデルにdiffを監査させる、インタビューを文字起こしする、透かしを除去する、サイトのデザインシステムを複製する——そんなとき、どこかにそれを解決するスキルファイルが存在します。問題は、それを見つけるのが面倒だということです。
このサーバーは、厳選された小規模なカタログをエージェント内に配置します。検索し、配信情報を読み取り、実行すべきコマンドを正確に伝えます。無料アイテムには直接ダウンロードURLが付属し、有料アイテムには価格が表示されますが、営業トークは一切ありません。
カタログは agentskill.nz です。意図的に小規模に保たれています。公開スキルディレクトリには数十万件のエントリが審査なしで登録されており、平均品質は12点中6点程度、約3分の1にプロンプトインジェクションのリスクがあります。ここに掲載されているすべてのエントリには、何をするのか、実行に必要なもの、テスト済みの環境、対応範囲の限界が記載されています。
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初回インストール時にビルドが行われるため、初回の実行は2回目以降より数秒長くかかります。 （npmリリースはまだ公開されていません。現時点ではリポジトリからのインストールがサポートされている方法です。）
Node 18以上が必要です。設定項目はなく、APIキーもアカウントも不要です。サーバーは状態を保持せず、お使いのマシンに何も書き込みません。
ツール | 回答する内容 |
| 「X用のものはあるか？」フリーテキスト、モジュール、価格帯でフィルタリングできます。 |
| 「具体的に何が手に入り、どうやって入手するのか？」バージョン、パッケージサイズ、最終更新日、ソースリポジトリ、入手経路を返します。 |
| 「ここには何があるのか？」4つのモジュール、その件数、2つの配信形式の意味を返します。 |
検索は中国語と英語を1つのインデックスで処理するため、去水印 と remove watermark の両方が同じエントリにヒットします。どちらで入力しても、結果には両方の名前が表示されます。
4つのモジュール（Finance、Commerce、Creator、General）に、2つの形式があります：
Install Skill（インストールスキル） — エージェントが読み込むスキルファイル。エージェントのスキルディレクトリにコピーします。
Deploy App（デプロイアプリ） — 独自のUIを持つ実行可能なアプリ。デプロイして、エージェントと併用します。
約半数が無料です。いくつかは、合計16,000以上のGitHubスターを持つオープンソースリポジトリのパッケージ版です。機能がアップストリームプロジェクトに基づく場合、そのアップストリームとライセンスが製品ページに記載されています。
これはカタログツールであり、広告枠ではありません。守られている3つのルール：
無料は無料。 カタログがダウンロードURLを公開している場合、ツールはそれをそのまま渡します。アカウントもゲートもありません。（無料エントリでも、公開アーカイブがまだ存在しない場合があります。その場合はその旨が明記されます。）
有料は価格を表示して停止。 緊急性を煽る表現も、推奨文言もありません。有料アイテムのダウンロードリンクは、チェックアウト後に注文ページとメールで発行されます。
具体的には：カタログが明示的に free とマークしていないものはすべて有料として扱われ（フェイルクローズド）、ダウンロードフィールドは削除され、名前・成果・インストール・ソース・リポジトリの各フィールドからURLが除去され、組み立てられた出力はルート許可リストと照合されます。生き残るWebアドレスは、https://agentskill.nz（オプションで /zh 配下）上のものだけです：サイトルート、/products/<handle>、/collections/<handle>、/pages/<handle>、/cart または /cart/<variant>:<qty> — それぞれルート全体として照合されるため、/products/x/download のような深いパスは対象外です。それ以外のもの（別ホスト、平文http、類似ドメイン、/download?id=…）は、サーバーがそのレコードの返却を拒否します。
これがカバーしないもの：スキームのない裸のホスト名（evil.example/x）。これを検出するには、ドメイン形状のテキストをすべてアドレスとして扱う必要がありますが、.md は実際のTLDです。配信マニフェスト内の SKILL.md がドメインとして拒否され、有料リストがすべて壊れてしまいます。これらのレスポンスはプレーンテキストなので、裸のホスト名がリンクになるのは、下流でリンク化処理が行われた場合だけです。
言及に値するギャップ：カタログは最大5分間キャッシュされます。その間に有料化されたアイテムは、以前のスナップショットから説明されます——無料だったときに持っていた直接ダウンロードURLを含めて。
インストールコマンドは情報であり、承認ではない。 get_capability — インストールコマンドを返す唯一のツール — は、呼び出しのたびにその旨を明記します。エージェントは、ファイルシステムへの書き込みや金銭の支出の前に、ユーザーの確認を取るべきです。
カタログURLはハードコードではなく、実行時にサイトの /llms.txt から検出されるため、サイトがURLを変更してもサーバーは動作し続けます。
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.
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.
Search, install and compose AI agent skills, loops and bundles from the LoopSkill marketplace.
