에이전트가 처리할 수 없는 작업에 직면했습니다 — 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최초 설치 시 빌드가 진행되므로 첫 실행은 이후 실행보다 몇 초 더 걸립니다. (아직 npm 릴리스는 없습니다. 현재 지원되는 방식은 저장소에서 설치하는 것입니다.)
Node 18+가 필요합니다. 설정할 항목, API 키, 계정이 없습니다. 서버는 상태를 보관하지 않으며 사용자 머신에 아무것도 기록하지 않습니다.
도구 | 답변하는 질문 |
| "X에 대한 것이 있나요?" 자유 텍스트, 모듈 또는 가격 등급으로 필터링합니다. |
| "정확히 무엇을 받게 되고, 어떻게 받나요?" 버전, 패키지 크기, 최종 업데이트, 소스 저장소, 획득 경로. |
| "여기 뭐가 있나요?" 네 개의 모듈, 각각의 항목 수, 두 가지 제공 형태의 의미. |
검색은 하나의 인덱스에서 중문과 영문을 모두 읽으므로 去水印과 remove watermark 모두 동일한
항목에 도달합니다. 어느 쪽으로 입력하든 결과에는 두 이름이 모두 표시됩니다.
네 개의 모듈 — Finance, Commerce, Creator, General — 두 가지 형태로 제공됩니다:
Install Skill — 에이전트가 로드하는 스킬 파일. 에이전트의 스킬 디렉토리에 복사합니다.
Deploy App — 자체 UI를 갖춘 실행 가능한 앱. 배포한 후 에이전트와 함께 사용합니다.
항목의 약 절반이 무료입니다. 여러 항목은 합산 16,000개 이상의 GitHub 스타를 보유한 오픈소스 저장소의 패키징된 형태입니다. 기능이 업스트림 프로젝트를 기반으로 하는 경우, 업스트림과 해당 라이선스가 제품 페이지에 명시됩니다.
이것은 카탈로그 도구이지 광고 슬롯이 아닙니다. 지키는 세 가지 규칙:
무료는 무료입니다. 카탈로그가 다운로드 URL을 게시하는 경우, 도구는 이를 그대로 전달합니다 — 계정도, 게이트도 없습니다. (무료 항목이 아직 게시된 아카이브가 없는 경우도 있습니다. 그렇게 명시됩니다.)
유료는 가격을 표시하고 멈춥니다. 긴급성 조장이나 추천 문구가 없습니다. 유료 항목의 다운로드 링크는 결제 완료 후 주문 페이지와 이메일로 발급됩니다.
구체적으로: 카탈로그가 명시적으로 free로 표시하지 않은 모든 항목은 유료로 처리되고(fail closed),
다운로드 필드는 제거되며, 이름, 결과, 설치, 소스 및 저장소 필드에서 URL이 제거되고, 조합된
출력은 경로 허용 목록(allowlist)으로 검사됩니다. 살아남는 웹 주소는 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.
